SPEC-DDD-FED · v0.4
28 June 2026
Owner: Platform team

Federation — the identity & tenancy bounded context

The platform's foundation context: tenancy and plans, identity and the federated session, the role & permission model, and the customer's organization structure. It is upstream of every other context — it publishes the token they all conform to. A supporting subdomain: bespoke multi-tenant identity that serves the core rather than differentiating.

1Ownership & boundaries

Foundation: ASP.NET Core Identity 10 (Entity Framework Core stores, Guid keys). The identity entities below are the framework's seven AspNet* tables — ApplicationUser · UserLogin · UserClaim · UserToken · ApplicationRole · ApplicationUserRole · RoleClaim — extended with the RiverSync columns; Tenant, Organization, Application, Permission & RolePermission are extensions with no Identity equivalent. See SPEC-PRD-FED §9 (FED-17) and the ERD's DM-32 / DM-33.

Federation is the only writer of these entities. It enforces the tenant type system — riversync · customer · partner, with customer + partner allowed to coexist on one organization and riversync exclusive — the rule that exactly the riversync tenant has no organization (TEN-3), one user account per tenant, one app-role per user per application (AUTH-1), and the organization-unit / region / site structure beneath each customer. It issues the federated token that every other service trusts.

Reads from: Coverage (the partner-scope resolver, for partner reads into structure) · Billing (profile bootstrap, via event). Account is the primary client (org, users, roles, structure); Admin provisions tenants; every app's BFF resolves identity here.

2Ubiquitous language

The words this context uses — the same in code, conversation and spec.

3Aggregates & invariants

The consistency boundaries — one root each, guarding its invariants in a single transaction; cross-aggregate ties are by identity.

4Context relationships

How this context meets its neighbours, with the integration pattern named on each edge.

5Physical view — the service API

The deployment mapping: this context becomes the Federation service, exposing these routes behind the gateway. Paths relative to api.riversync.com/v1; access notation per the master.

6Domain events

The past-tense facts this context publishes (and consumes) — its share of the platform's published language.

7Invariants in play

The modeling rules that bind this context — the master holds the full set; data integrity stays with the ERD drill-downs.

8Revision history

Version	Date	Changes
0.1	13 Jun 2026	First draft — Tenancy, Identity and Structure merged into one Federation service (SPEC-DDD v0.6). Owns the union of their entities; routes, events and SVC-rules recomposed from the central catalog.
0.2	14 Jun 2026	Identity foundation set to ASP.NET Core Identity 10 (SPEC-DDD v0.8 / SPEC-ERD v0.13 / SPEC-PRD-FED v0.4) — owned identity entities are now the seven AspNet* base tables (ApplicationUser/ApplicationRole/ApplicationUserRole on IdentityUser/IdentityRole/IdentityUserRole<Guid>, plus UserLogin/UserClaim/UserToken/RoleClaim) extended with the RiverSync columns; ownership note + EmailConfirmed wording. Routes and events unchanged.
0.3	15 Jun 2026	Owned structure entity SiteLocation → OrganizationSite (SPEC-DDD v0.9 / SPEC-ERD v0.16). No boundary, route or event changes.
0.4	28 Jun 2026	Reframed as a Domain-Driven Design context (with the set, SPEC-DDD v0.14) — leads with ubiquitous language & aggregates (Tenant, ApplicationUser, ApplicationRole, OrganizationStructure) and the context relationships (upstream open-host identity that every context conforms to; the ACL bridge from Sales). The /federation API is demoted to the physical view. No ownership change.